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Abstract 

A strategy for automatically generating and 
verifying simple computer programs is described. 
The programs are specified by a precondition and 
a postcondition in predicate calculus. The programs 
generated are in the Lucid programming language, a 
high-level, data-flow language known for its attrac- 
tive mathematical properties and ease of program 
verification. The Lucid programming language is de- 
scribed, and the automatic program generation strat- 
egy is described and applied to several example prob- 
lems. 

Introduction 

There are currently numerous projects to inves- 
tigate the automation of program verification us- 
ing automatic theorem-proving approaches. These 
verification systems often use the same type of de- 
ductive reasoning used by the programmer to cre- 
ate the program being verified. Automatic program 
verification is difficult and requires a highly detailed 
program specification. However, when the specifica- 
tion is sufficiently detailed, automatic generation of 
proven programs is only slightly more difficult. Most 
attempts at automating program generation assume 
the given specification expresses only the basic func- 
tion the program is supposed to perform without any 
hint of an algorithm to be used. However, analysis of 
simple program specifications reveals that the speci- 
fication plus basic knowledge of mathematics usually 
leads the programmer to a specific algorithm. 

The goal of most attempts to automate pro- 
gram generation has been to save time and effort 
on the part of the programmer or to enable some- 
one with limited knowledge of computers to produce 
programs. The goal of this study, however, is the 
generation of highly reliable software. For applica- 
tions in which failure of the software could result in 
loss of life or property, standard testing is inadequate 
and more elaborate techniques such as fault-tolerant 
software and program proving are necessary. 

This paper describes a strategy for automatically 
generating and verifying simple computer programs 
in the Lucid programming language (ref. 1) from a 
precondition and a postcondition specified in predi- 
cate calculus. The programs generated are correct, 
but they are not necessarily efficient. Lucid is a 
high-level, data-flow programming language known 
for its attractive mathematical properties and its ease 
of program verification. Lucid statements are actu- 
ally assertions about the relationships between pro- 
gram variables. These statements can easily be com- 
bined with axioms defining the Lucid programming 


statement semantics to produce a proof of program 
correctness. 

The inputs to the system are axioms defining the 
precondition and the postcondition of the program 
to be generated. The automatic program genera- 
tion system contains a data base of basic axioms 
of mathematics and of axioms defining Lucid pro- 
gram statements. The axioms from the data base are 
used to generate the program automatically. There- 
fore, incorrect programs cannot be generated. (Even 
though the code is proven correct, the compiler could 
still introduce errors.) The eventual termination of 
the program is also proven, a step which is missing 
in most program verification systems. Thus, total 
correctness of the program is proven. 

The strategy was inspired by a theorem-proving 
approach which used the principle of mathemati- 
cal induction described by Manna and Waldinger 
in the early 1970’s. (See ref. 2.) Most of the 
early work on automatic program generation used the 
theorem-proving approach. Because iterative pro- 
grams were difficult to represent with this approach, 
the theorem-proving approach was abandoned in fa- 
vor of applying transformation or rewriting rules to 
the program’s specification. (See refs. 3 to 7.) In 
most of these systems, the transformation rules ap- 
plied to the program specification are chosen with 
little or no strategy. There may be an ordering to de- 
cide which applicable rules are used first, and back- 
tracking occurs when the system runs into a dead 
end, but rules are basically applied in an ad hoc 
manner until some program eventually aoDears. The 
automatic program generation strategy described in 
this paper uses a theorem-proving approach, but con- 
trolled searching is added to handle iteration. Anal- 
ysis of the form of the specifications is used to guide 
the application of rules and axioms in a very con- 
trolled manner. 

The strategy can generate only short, simple 
programs. However, a typical large, complex pro- 
gram is a collection of relatively simple tasks. The 
strategy requires a complete, detailed specification 
for each task. If the program specification is at the 
level of the simple tasks, then each of the tasks can be 
generated by the automatic program generator, and 
the complex program can then be assembled from the 
tasks. 

Proving that the code is a correct implementa- 
tion of the specification is almost worthless unless 
the specification itself is known to be correct. This 
is especially a problem since the specification re- 
quired is at such a low level of detail. The specifica- 
tion must be proven to accurately represent a high- 
level, abstract program specification. This proof can 
be accomplished by refining an abstract program 



specification (possibly in natural English) into more 
and more detailed hierarchical levels and proving 
consistency with automatic theorem provers until 
the detailed specification needed for the automatic 
program generator is reached. A hierarchical spec- 
ification methodology was developed by SRI Inter- 
national and was demonstrated by application to 
the proven operating system for the Software Im- 
plemented Fault Tolerance (SIFT) computer. (See 
ref. 8.) The lowest level of specifications of the SIFT 
operating system used by SRI International in their 
code proof contains enough detail for input to the 
program generation strategy. The use of a hierarchi- 
cal specification methodology can also aid in the diffi- 
cult problem of developing a correct program control 
structure above the basic tasks. 

Because the synthesis of loops has been the most 
difficult part of automatic program generation, most 
of the discussion in this paper concerns the genera- 
tion of loops with this strategy. The Lucid program- 
ming language is described, and then the basic in- 
duction strategy is described and applied to several 
example programs. The limitations of the strategy 
are then discussed. 

Symbols 

A logical and 

V logical or 

V for all 

3 there exists 

-i not 

-L undefined element 

— > implies 

x/y every instance of x is replaced by y 

G |= A the truth of A is implied by the truth 
of every assertion in G 

The Lucid Programming Language 

The automatic program generator creates 
programs in Lucid. A formal description of Lucid is 
not given here but may be found in reference 1. Lu- 
cid is a very high-level programming language. The 
ultimate goal of a high-level language is to make pro- 
gramming easier. A problem with most high-level 
languages today is that these languages are so com- 
plex that the program logic is obscured by the im- 
plementation detail. Lucid control structures are at 
a much higher level of abstraction. The way a Lucid 
program is specified is closer to the way people think 


and farther from machine implementation than con- 
ventional languages. Thus, Lucid programs are easier 
to understand than programs written in conventional 
programming languages. What is unconventional 
about Lucid is that the nonmathematical features 
of popular languages have been removed, such as as- 
signment statements that assign new values to exist- 
ing variables (e.g., x — x + 1) and branching state- 
ments. The only sequencing constraints are those 
implicit in the data dependencies of the program. 
Function definitions describe the results produced 
when the functions are evaluated, and these descrip- 
tions are precisely the assertions needed for proving 
correctness. 

Lucid was developed for its attractive mathemat- 
ical properties and its ease for program verification, 
and it is additionally suitable as a language for data- 
flow computers. The language is being used exper- 
imentally at a number of universities and research 
institutes, including the University of Arizona, the 
University of California at Berkeley, and SRI In- 
ternational. Lucid can express computations with 
widely differing behaviors of interest to NASA, for 
example, iterative algorithms, recursive algorithms, 
history-sensitive computations, computations with 
high degrees of parallelism, and signal-processing 
algorithms. 

Although Lucid is not a widely used language, 
it has several features conducive to automatically 
generating programs. These features include the 
following: 

1. Variables are defined inductively. 

2. No side effects from assignments are present. 

3. Variables are not history sensitive. 

4. An axiomatic definition of Lucid is available. 

Lucid has a “single assignment” convention. This 
convention makes Lucid a definitional language in- 
stead of a conventional imperative language. In an 
imperative language, the assignment statement mir- 
rors the implementation of variable storage; that is, 
an assignment replaces the contents of a storage lo- 
cation with a new value. The assignment state- 
ment in Lucid, however, defines the relationships 
between variables, making Lucid a definitional lan- 
guage. These relationships may be defined only once 
for a given variable, and the relationship is an asser- 
tion which holds for the variable throughout the en- 
tire program block. The values of the loop variables 
do change upon each iteration of a loop. The single 
assignment rule still holds within any one iteration 
cycle, because all redefinitions take place precisely 
at the boundary between iteration cycles. Since the 
assertions hold during each cycle, an inductive proof 
may be used in proving correctness of iteration. 
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Another feature convenient for automatic pro- 
gram generation is that assignment statements in 
Lucid have no side effects. This simplifies the proof 
considerably because no variables other than the 
one assigned to can be affected by an assignment 
statement. 

The program generation strategy, as described in 
this paper, will not work for traditional programming 
languages such as Pascal and FORTRAN. Consider, 
for example, the code to swap two variables. The 
postcondition of the specification would be that the 
new value of y equals the old value of x and the new 
value of x equals the old value of y (</ = x A x' = y). 
The Pascal code would be 

temp := x ; x := y; y := temp; 

which involves the use of a temporary variable. The 
Lucid code would be 

next x = y; next y — x; , 

which requires no temporary variable. The genera- 
tion of the Lucid code in this case is very straightfor- 
ward from the specification; however, the generation 
of the Pascal code requires the addition of an in- 
ternal variable not mentioned in the specification. It 
would be difficult to construct an automatic program 
generator that would know to use a temporary vari- 
able. This ties in with the history-sensitivity prob- 
lem uf axioms only being true at certain points in the 
program. 

The only sequencing constraints in Lucid pro- 
grams are those caused by data dependencies. Since 
each assertion holds for the entire program block, the 
order of statements in a Lucid program is not impor- 
tant. In Lucid, the program statements are axioms 
that can be used in the proof, and the axioms in the 
proof are always true, not just after certain state- 
ments have been executed, so the proof is easier to 
keep track of and to automate. 

An axiomatic definition of Lucid for perform- 
ing program proofs was developed by Ashcroft and 
Wadge (see refs. 9 to 11). These proofs are simi- 
lar in form to those developed for Pascal proofs by 
Hoare (see ref. 12). The proof of Lucid programs is 
discussed briefly in the section Program Proving in 
Lucid. The reader is directed to reference 9 for a 
more formal definition of the Lucid language and of 
proving Lucid programs correct. 

A complete formal definition of the Lucid pro- 
gramming language is beyond the scope of this 
paper. Instead, a subset of the language sufficient 
for implementing a simple program is described. 


Assignment Statements 

Unlike the programming languages commonly in 
use today, Lucid assignment statements are mathe- 
matical equations. In Pascal, the assignment state- 
ment mirrors the implementation of storage — an as- 
signment replaces the contents of a storage location 
with a new value, which may be based on the pre- 
vious value. The Lucid assignment statement, how- 
ever, is an axiom about the relationships between the 
variables in the program. For example, the assign- 
ment statement x = y + 2 means that every instance 
of the variable x can be replaced by y + 2. 

This concept is carried through in Lucid with 
the definition of variables inductively. The first 
occurrence of a variable x is denoted by 

first x — “expression”; 

where “expression” is syntactically constant (i.e., 
built up from data constants, terms of the form 
first x or x as soon as P. and other variables 
syntactically constant). Subsequent occurrences are 
defined inductively by 

next x = “expression”; 

where “expression” represents the relationship to 
other inductively defined variables or input variables. 
The current value of the variable x may be denoted 
simply by x. 

A variable can also be defined with the 
followed by statement, where 

x = “expression 1” followed by “expression2” ; 
is equivalent to 

first x = “expression 1”; next x = “expression2” ; 

Similarly, we may define a loop variable by defin- 
ing each current value of the variable as a relationship 
of other variables: 

x — “expression”; 

where “expression” leads ultimately to a relationship 
to inductively defined variables. For example, the 
statement 

x = first y + z\ 

defines the current value of the variable x to be the 
first value of y plus the current value of z. 

The definition of the first value of a constant 
and the next value of a constant is the value of the 
constant; thus, 

c = first c = next c 
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Every variable used on the right-hand side of a 
definition must be defined once, and only once, in 
the program block unless it is an input variable. 

Input and Output 

There are no explicit input statements in Lucid. 
Input of a variable is implicit by reference to the vari- 
able on the right-hand side of an equation. A variable 
to be input is never defined by an assignment state- 
ment or inductive definition. Output of variables is 
denoted by an equation of the program or function 
name to the variables in the program statement, as 
shown in the following example program: 

MULT = y 

where 

y = x * z; 

end; 

Iteration 

Iteration is implied by variable definitions instead 
of by mathematically meaningless transfer state- 
ments. The as soon as construct is used to extract 
values from loops and iteratively defined variables, 
as in the following: 

z = x as soon as x > y\ 

Termination of a loop is implied when all as soon 
as expressions have been satisfied. 

Conditional Statements 

Conditional statements in Lucid affect variables 
instead of program flow, as shown in the following 
example: 

next x = if x > y then x else y; 

Program Proving in Lucid 

The axioms necessary for proving Lucid programs 
correct were developed by Ashcroft and Wadge and 
are explained and proven to correctly describe the 
language in reference 9. The axioms needed for the 
proofs performed in this paper are briefly described 
in this section. The reader is directed to reference 9 
for a more formal discussion of the definition of 
the Lucid language and of proving Lucid programs 


correct. 

The following definitions 

axioms 

described in this section: 

P, Q 

expressions 

X‘i 

variables 

G 

finite set of terms 

± 

undefined element 


The notation x/y means every instance of the vari- 
able x in an expression is replaced by the variable y. 
For any assertion P and set of assertions G, G f= P 
means that the truth of P is implied by the truth of 
every assertion in G. 

The Commutativity Axioms allow the movement 
of the qualifiers first and next into and out of 
expressions in which all elements fit the qualification, 
much like existential quantifiers can be moved in 
logical proofs. For free variables x\, X 2 , ..., x^, 

first P = P(xi /first xi, X2/first X2, ••■) 

next P = P(xy/ next aq, x^/next X2,...) 

For example, first (aq + £ 2 ) — first x\ + first x^- 

The following axioms provide for further manipu- 
lation of the first, next, and as soon as statements: 

(first first P = first P) A 
(next first P = first P) 

and 

P as soon as Q — if first Q then first P 

else (next P as soon as next Q) 

Loops in a Lucid program are defined by the as 
soon as Induction Rule, as follows: 

first P, P A -i Q — *■ next P, eventually Q (= 
P A Q as soon as Q 

Termination of a Lucid program can be proven 
with the Lucid Termination Rule: 

integer P, P > next P (= eventually P < 0 

In addition to the above axioms defining Lucid 
statements, any axioms or rules of inference from 
ordinary logic may be used in Lucid proofs that are 
valid in the presence of an undefined element _L. For 
example, the statement for every x, the condition 
x = x + 1 is not valid because _L = _L +1. Also, 
traditional methods of reasoning by contradiction are 
not valid because of the undefined element. However, 
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the following two axioms are valid for reasoning by 
contradiction: 

(A = True) V -> (A = True) — ► True 

and 

(. A — ► False) — ► -> {A = True) 

The first axiom states that it is always true that 
(A = True) is true or ( A = True) is not true. The 
second axiom states that the truth of the condition 
(A — ► False) implies that the condition {A = True) 
is not true. 

Proof of Correctness of a Lucid Loop 

This section describes how the Lucid as soon as 
construct is used to build a loop and how such a loop 
may be proven correct. The following sections then 
explain in detail how a loop built around this Lucid 
construct may be automatically generated. The 
notation in this paper is as follows: input variables 
are denoted aq, X2 , ..., and internal and output 
variables are denoted y\, 2/2 , .... 

We want to write an iterative program to compute 
the integer quotient and remainder of two natural 
numbers aq and aq, where X2 > 0. The specifications 
of the program are as follows. The precondition for 
the program is 

pre: X2 > 0 

and the postcondition is 

post: (aq = y\ * x 2 + 2/2) 

A (2/2 < x 2 ) A (2/2 > 0) 

where 2/1 is the integer quotient and 2/2 is the 
remainder. 

We will start with y\ = 0 and keep incrementing 
2/i by one until the difference between (2/1 * X2) and 
xi, which is equal to the remainder y2, is less than 
aq- We thus define 2/1 inductively as 

first 2/1 = 0 ; next 2/1 = 2/1 + 1 ; 

While we are determining the quotient 2/1, we also 
need to keep track of the remainder 2/2 to determine 
when to stop the iteration. For this, we define 2/2 
inductively as 

first 2/2 = aq; next 2/2 — 2/2 - aq; 

These two inductive definitions of variables 2/1 and 
2/2 create the loop to perform the division. Next, we 
need to make the program execution terminate when 
the remainder 2/2 is less than X2 , and we need to make 


the program output the quotient and remainder. We 
accomplish this using the as soon as statement on 
the program statement, as follows: 

IDIV = (221,2/2) as soon as (2/2 < £2); 

The entire program is thus 

(51) IDIV = (2/1, 2/2) as soon as (y 2 < aq); 

(5 2 ) where 

(5 3 ) first 2/1 = 0 ; 

(5 4 ) first 2/2 = aq; 

(5 5 ) next 2/1 = 2/1 + 1 ; 

(5 6 ) next y 2 = 2/2 - aq; 

(5 7 ) end; 

A proof that this program correctly implements its 
specification is described below. 

In Lucid, as in other programming languages, a 
loop is proven through use of a loop invariant and 
a termination condition. The loop invariant is an 
assertion which is true on each iteration of the loop. 
The loop invariant describes the relationships of the 
variables used in the loop. The termination condition 
is an assertion which is false initially and on each 
iteration of the loop until the final iteration, when it 
becomes true. 

All the axioms used in the proof are described in 
the section entitled The Data Base. These are the 
same axioms which are used in a subsequent section 
to generate the same program with the automatic 
program generation strategy. 

Since the program is based around the as soon 
as function, we will base the proof on the Lucid as 
soon as Induction Rule. There are three conditions 
we need to prove true about the program. Using the 
precondition specified, we must show that the loop 
invariant equation is true for the initial values chosen 
for the variables. We must also prove that if the 
invariant equation is true for the variable values for 
the current iteration and if the termination condition 
is not true, then the invariant equation will be true 
for the variable values on the next iteration. To 
prove total correctness, we must also prove that the 
termination condition will eventually be true, so the 
program will eventually terminate. 

The Lucid as soon as Induction Rule is 

first P, P A -i Q — ► next P, eventually Q (= 

P A Q as soon as Q 

where P is the loop invariant, and Q is the 
termination condition. For any assertion A and set 
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of assertions G,G \= A means that the truth of 
A follows from the truth of every assertion in G. 
So once we prove the three assertions eventually 
Q, first P, and P A -> Q — > next P are true for 
the P and Q in our program, then we have proven 
P A Q as soon as Q. This proves that the loop will 
eventually terminate and that when it terminates, 
the loop invariant and the termination condition will 
both be true. 

For this program, the loop invariant P is 
(zi = y\ * 22 + 2/2) 
and the termination condition Q is 
(y 2 < x 2 ) 

The proof then proceeds by our proving each of the 
following three conditions: 

first P 

P A -i Q — > next P 
eventually Q 

The definitions for the Lucid programming state- 
ments and the theorems and axioms used in the proof 
are contained in the section entitled The Data Base. 


Proof of first P: 

1. xi =0 + a:i 

2 . X2 * 0 = 0 

3 . xi = 0 * X2 + xj 

4 . x\ = first 2/1 * X2 

+ xi 

5 . xi = first yi * X2 

-I- first 2/2 

6 . first (xi = 2/1 * %2 

+ V2 


Identity of addition 
Substitution property 
of 0 

1,2, substitution 

3, definition of first 
(from (S3)) 

4, definition of first 
(from (S4)) 

5, commutativity of 
first 


Proof of P A -1 Q — »• next P 


1 . xi = yi * X2 + 2/2 

2 . X2 — X2 = 0 

3 . xj = 2U * x 2 + 2/2 

+ X2 — x 2 

4 - xi = (2/1 * x 2 + x 2 ) 
+ (V2 ~ x 2 ) 

5. 1 * 2 = X 2 


Given assumption P 
Identity of subtraction 
1,2, identity of addition 

3, associativity of 
addition 

Identity of 
multiplication 


6. 2/1 = * X 2 + 1 * X2 

4,5, substitution, 

= (yi + 1) * x 2 

distributivity of 
multiplication over 
addition 

7. 21 = (yi + 1) * X 2 

4,6, substitution, 

+ (l/2 - 22 ) 

identity of 
multiplication 

8. xi = next yi * X 2 

7, definition of next 

+ (l/2 - 22 ) 

(from (S5)) 

9. xj = next yi * 12 

8, definition of next 

+ next y2 

(from (S6)) 

10. next (xi = yi * X 2 

9, commutativity of 

+ V 2 ) 

next 

Proof of eventually Q 

1. X2 > 0 

From precondition 

2 - V 2 > V 2 ~ 2 2 

1 , if a > b then 
c — b > c — a 

3. y 2 > next y 2 

2 , definition of next 
(from (S6) ) 

4. y 2 — 22 > next y 2 

3, if 0 > b then 

- 22 

a — c > b — c 

5. V 2 ~ 22 > next (y 2 

4, commutativity 

- 22) 

of next 

6. eventually (y2 — 22) 

5, Lucid Termination 

< 0 

Rule 

7. eventually y2 — 22 

6, if a < 6 then 

+ 22 < 22 

a + c < 6 + c 

8. eventually y 2 < 22 

7, identity of 
subtraction 

Through use of the as soon as Induction Rule 

the three proofs above, 

P A Q as 

soon as Q 


The Automatic Program Generator 

A brief look at the current state of the art in au- 
tomatic theorem provers provides some insight into 
how an automatic program generator might be im- 
plemented. The user typically inputs the theorem to 
be proven and enumerates all the axioms necessary 
to perform the proof. If the theorem prover is unsuc- 
cessful, then the user must supply more information, 
such as additional axioms or a matchup of the vari- 
ables in the theorem with the variables in the axioms 
to be used. An interactive “debugger” assists the 
user in determining what information is needed by 
the theorem prover. The proof is attempted repeat- 
edly until eventually the user has supplied enough 
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hints that the theorem prover “sees” the scheme to 
produce the proof. 

The automatic program generator could use a 
similar interactive scenario. The user would first 
input the precondition and the postcondition which 
specify the program to be generated. The user would 
then instruct the program generator to attempt the 
code generation using axioms available in its data 
base. If the automatic program generator was not 
successful within a set amount of time, the user 
would supply more information. An interactive de- 
bugger could list all the applicable axioms in the data 
base and the user could highlight certain axioms that 
might lead to programs, or the user could supply 
additional axioms to be used. The user could also 
identify the matchup of the variables in the precon- 
dition and the postcondition with the variables in 
the axioms to be used in the code generation. The 
user could keep instructing the program generator to 
retry with more and more information until finally 
the program generator would “see” the scheme to 
automatically generate the code. In the worst case 
scenario, the automatic program generator would be 
no more help to the user than current automatic 
theorem provers, with which the user must essen- 
tially provide the code and come up with the proof 
scheme, after which the theorem prover mechanically 
performs and verifies the proof. However, in the 
best case scenario, the automatic program generator 
would be of tremendous help in generating a proven 
code. 

Inputs to the Program Generator 

If we assume a sufficient data base of mathemat- 
ical axioms is present, the only inputs to the auto- 
matic program generator are the precondition and 
the postcondition in predicate calculus specifying the 
program. These conditions must be sufficiently de- 
tailed to define each loop and action that must be 
performed in the program. If the program specifi- 
cations are not detailed enough to include a neces- 
sary loop invariant, the automatic program gener- 
ation strategy may fail because the loop invariant 
cannot be deduced. Current strategies for automat- 
ically generating loop invariants for automatic pro- 
gram verification rely on having the code in hand. 
(See ref. 13 .) If the program to be generated is for 
a life-critical application and must be verified as cor- 
rect, this requirement of detailed specification is not 
unreasonable. 

The Program Generation Approach 

The strategy for generating loops was developed 
from an examination of the way loops are proven. As 


shown in the example in the last section, the proof of 
correctness of a loop revolves around a loop invariant 
and a termination condition. The loop invariant 
and the termination condition are usually explicitly 
stated in the postcondition. In the example, the 
postcondition (aq = y i * a; 2 + 2/2) A (2/2 < ^2) 
was made up of the loop invariant (aq = 2/1 * x 2 + 2/2) 
and the termination condition (2/2 < £2)- The 
construction of the loop is usually clear from the loop 
invariant and the termination condition. 

Since all Lucid loops are based on the as soon 
as function, they are all constructed with the same 
basic strategy. The strategy consists of examining 
the precondition and the postcondition to find loop 
invariants, termination conditions, or other phrases 
to determine the form of construction for the loop. A 
data base of mathematical axioms and Lucid proof 
rules is then systematically searched for applicable 
rules and axioms to construct the loop. 

The automatic program generation is done in two 
steps, analysis and program generation. The anal- 
ysis step involves choosing the loop invariant and 
the termination condition for generating the program 
based on the form of the precondition and the post- 
condition given. The condition predicates are simple 
clauses separated by logical and’s. The clauses are 
examined to identify possible loop invariants, loop 
directions, termination conditions, conditionals, etc. 
The program generation step then uses a data base 
of Lucid statement rules and basic mathematical ax- 
ioms to generate the program guided by the chosen 
loop invariant and termination condition. 

The purpose of a loop is to repeatedly perform 
some process. The process may be some computa- 
tion, such as repeatedly multiplying to perform in- 
teger exponentiation, or it may be some test over a 
range, such as testing for divisors to determine if a 
number is prime. The number of repetitions of the 
loop is usually guided by a control variable. The 
control variable is inductively defined to count the 
correct number of repetitions or to enumerate all 
members in a range to be tested. The termination 
condition is used to determine that the control vari- 
able has finished counting the correct number of iter- 
ations or that all members in the correct range have 
been tested. The loop invariant defines the compu- 
tation or test to be performed. The output variables 
other than the loop control variable are also defined 
inductively to keep the loop invariant true on each 
repetition. 

Preconditions identify the input variables and 
their ranges, but they are usually of little help in 
identifying a possible algorithm. The clauses of the 
postcondition are classified according to type, as 
explained in the following subsections. 
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Termination conditions are usually simple clauses 
consisting of an input variable, a Boolean oper- 
ator, and an output variable, such as y\ < x\. 
Termination conditions can sometimes be used to de- 
termine the direction of induction (i.e., whether the 
loop control variable is “going up” or “going down”). 
For example, y\ < x\ or y\ < x\ usually means 
going-down induction, y\ > x\ or y\ > x\ usually 
means going-up induction, and yi = x\ or y\ ^ x\ 
does not indicate a direction of induction. 

Loop invariants are equations defining relation- 
ships between one or more output variables and one 
or more input variables, such as 

x\ = 2/i * x 2 + 2/2- 

Many simple one-loop routines are specified only 
by a loop invariant and a termination condition. An 
example of this type of routine is given in the Ex- 
ample section, and the program generation strategy 
is shown in detail. A loop is not always defined by 
both an invariant and a termination condition. The 
termination condition is not always present, and the 
loop invariant is not always easy to identify. The 
following is an example of a loop which seems to be 
specified with two termination conditions. One of 
the termination conditions may be used as a loop 
invariant. 

pre: integer x > 0 

post: integer y A (y 2 < x) A (x < (y + l) 2 ) 

These conditions specify a program to calculate an 
integer square root. The first clause (y 2 < x) is a 
good choice for a loop invariant because it is easy to 
choose a first value for y that will satisfy this clause. 
A first value for y to satisfy ( x < (y + l) 2 ) would 
not be so trivial to find. 

Construction of a Loop From an Invariant and 

a Termination Condition 

As shown above, a loop may be identified by a 
loop invariant and a termination condition. The 
strategy described in this section is for a single loop. 
This strategy would be repeated for each loop in a 
complex program. 

Once the loop invariant, the termination condi- 
tion, and the induction direction are selected, the 
loop is constructed. The loop construction is de- 
signed around the same Lucid as soon as Induction 
Rule used in the proof of correctness: 

first P, P A -■ Q — > next P, eventually Q |= 

P A Q as soon as Q 


where P is the loop invariant and Q is the termi- 
nation condition. Program generation proceeds with 
the following basic steps. 

Select initial variable values. Once the loop invari- 
ant is chosen and the loop direction is determined, 
the initial variable values must be selected. This is 
done by searching the data base for axioms which 
can be used to define initial values of the variables to 
make the invariant trivially true. For example, if an 
initial value of zero is chosen for a variable x, then all 
other variables multiplied by x essentially disappear 
from the initial invariant equation. 

For going-up induction, the initial control vari- 
able value may be some value, such as zero or one, 
which is a basic identity of the mathematical oper- 
ations involved. For going-down induction, the ini- 
tial control variable value may be equal to some in- 
put variable value. The search of the data base is 
then guided by the operations being specified by the 
already-identified invariant and the possible induc- 
tion direction being suggested by the termination 
condition. This section satisfies the clause first P 
in the as soon as Induction Rule. If no initial vari- 
able values can be found to satisfy the invariant, then 
another loop invariant should be chosen. 

Define variables inductively to keep invariant true. 

Once the initial variable values are defined, the y vari- 
ables must be defined inductively to keep the invari- 
ant true throughout the program. The direction of 
this induction may have been determined when the 
precondition and the postcondition were examined. 
This section satisfies the clause P A -i Q — > next P 
in the as soon as Induction Rule. 

Prove loop termination. Eventual loop termina- 
tion should then be proven with the Lucid Termina- 
tion Rule 

integer P, P > next P f= eventually P < 0 

The program construction is then completed by in- 
clusion of the as soon as statement to define the 
loop. The format of the entire program is as follows: 

pname = y 1; y 2 , ..., y n as soon as Q 

where 

first yi = ai(xi, x 2 , yi, y 2 , 
first y 2 = a 2 (...); ... first y n = ... 
next yi = gi(x u x 2 , ..., yi, y 2 , ...); 

next y 2 = y 2 (...); ... next y n = ■■■ 
end 
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where a n is a function defining the initial value of 
variable y U) g n is a function inductively defining 
variable y n , and Q is the loop termination condition. 

The following sections contain three examples of 
how to generate simple one-loop programs. The pre- 
condition and the postcondition specifying each pro- 
gram are shown, and the step-by-step construction 
is explained. The contents of the data base needed 
to generate each program are listed. The first ex- 
ample is the same integer division program that was 
constructed and proved in a previous section. The 
axioms used to automatically generate the program 
are the same axioms used previously in the proof of 
correctness of this program. 

Example 

The precondition and the postcondition for a 
program to perform integer division are as follows: 

pre: x\, £2 integers; £2 > 0 

post: (£1 = y\ * £2 + 2/2) A (2/2 < X2) A (2/2 > 0) 

If we assume an adequate data base of mathematical 
axioms exists, the precondition and the postcondition 
are the only inputs needed to automatically generate 
the program. The construction of this one-loop 
program then proceeds automatically through the 
steps outlined in The Automatic Program Generator 
section and is illustrated below. 

Classify Condition Clauses 

The first step is to examine the precondition and 
the postcondition to determine a loop invariant and 
a termination condition. The precondition identifies 
the input variables and their ranges. The postcon- 
dition is separated into two clauses separated by a 
logical and (A). 

The first clause (£1 = 2/1 * £2 + 2/2) is used as 
the loop invariant, because it is an equation defining 
the relationships between the two output variables 
and the two input variables. The second clause 
(2/2 < X2) is used as the termination condition — 
a simple clause consisting of an input variable, a 
Boolean operator, and an output variable. Since the 
output variable involved is 2/2 and its relationship to 
the input variable is the inequality <, the induction 
is on t/2 and the induction is with 2/2 decreasing. 

Algorithm Synthesis 

In the previous step, we determined that the loop 
invariant is (£1 = 2/1 * £2 + 2/2) and the termination 
condition is (2/2 < £2)- The algorithm synthesis pro- 
ceeds with the selection of initial variable values, the 


inductive definition of variables to keep the invariant 
true, and the proof of loop termination. 

Select initial variable values. The goal is to 
select initial variable values to make the invariant 
£l = (first 2/1 * £2) + first 2/2 trivially true. The 
induction is on 2/2 decreasing, so the initial value of 2/2 
is probably a function of the input variables instead 
of a 0 or 1. The data base is searched for basic axioms 
such as identity axioms over the multiplication and 
addition operations, since these are the operations 
in the invariant. The basic axioms for these two 
operations are 

a + 0 = a 
a * 0 = 0 
a * 1 = a 

To fill in the invariant equation x\ = (first 2/1 * 
£2) + first 2/2 , the main operator is addition and its 
identity equation is a + 0 = a, so either 

(first 2/1 * £2) = £1 A first 2/2 = 0 
or 

(first 2/1 * £2) = 0 A first 2/2 = £1 

The first set of equations is rejected because the 
equation (first 2/1 * £2) = xi has no integer solution 
for first t/i to satisfy all possible £1 and £2. The 
second alternative is chosen because with the basic 
equations for the operation multiplication, the first 
equation (first 2/1 * £2) = 0 can be satisfied by use 
of first 2/1=0 and first 2/2 = £1 can be satisfied 
by assignment. The initial value for the invariant 
equation is thus chosen as (£1 = 0 * £2 + £1), 
and therefore 

first 2/1=0 
first 2/2 = £1 

Define variables inductively to keep invariant true. 

To determine the method by which 2/2 should be 
decremented, the data base is searched for relation- 
ships between the multiplication and addition oper- 
ations, since these are the two operations in the in- 
variant. The search of the data base locates axioms 
such as distributivity of multiplication over addition; 
that is, 

a* (b + c) = a*b + a*c 

The variable 2/2 can decrease by 1, £1, £2, or 2/1 (or 
by some combination of variables). The goal is to find 
a way to decrease 2/2 and modify the other variables 
of the invariant (2/1 is the only other variable in this 


9 


case) while keeping the invariant true. Four obvious 
cases of decreasing y 2 by 1 or by a simple variable 
are examined. 

Case one is to decrease 1/2 by 1: 

x\ — y\ * X2 + 1 + (2/2 ~ 1) 

This gets us nowhere because there is no integer 
solution to satisfy next y\ — {y 1 * X2 + l)/x 2 , 
so there is no easy way to define y\ inductively to 
eliminate the added 1. 

Case two is to decrease 2/2 by x\: 

x\ = yi * X2 + xi + (2/2 - 11) 

The variable x\ is not guaranteed positive in the 
precondition, so this may not decrease 2/2- But more 
importantly, there is no integer solution to satisfy 
(2/1 * x 2 + Xi)/x2 , so there is no easy way to 
inductively define 2/1 to get rid of the added xi and 
keep the invariant true. 

In case three, 2/2 is decreased by X2- 

x\ = 2/1 * x 2 + X2 + (2/2 - x 2) 

Applying the distributive law described above plus 
the axiom a * 1 = a results in xi — (y\ + 1) * 
x 2 + (2/2 — x 2 ), so the variable 2/1 can be inductively 
defined as next y\ — y \ + 1 and the invariant 
is kept true. With the precondition x 2 > 0, this 
algorithm is guaranteed to decrease 2/2 • Case three 
looks like a possible algorithm. 

In case four, y 2 is decreased by 2/1 : 

xi = 2/1 * x 2 + 2/1 + (2/2 ~ 2/i) 

Applying the distributive law results in 

x\ = (2/1 + 2/1/12) * x 2 + (1/2 - 2/1). The 
variable y\ can be defined inductively to keep the in- 
variant true; however, since the initial value of 2/1 is 
0, 2/2 is not decreased and the program runs forever 
and does nothing. This problem would be caught by 
the program generator at this step or in the next step 
when termination is proven. 

The four cases examined above lead to one possi- 
ble induction algorithm — decrease 2/2 by x 2 at each 
iteration. The two variables are thus inductively 
defined as 

next 2/1 — 2/1 + 1 
next 2/2 = 2/2 - x 2 

Prove loop termination. Termination is proven by 
use of the Termination Rule as follows: 

integer P, P > next P |= eventually P < 0 


The termination condition is (2/2 < x 2 ), or (y 2 —x 2 < 
0), so with P = 2/2 — x 2 we get the following: 

1 . X2 > 0 From precondition 

2 . 0 > 0 — X2 If a > b then a — c 

> b — c, identity of 
subtraction 

3 . (2/2 — x 2 ) > (j/2 — X2) If a > 6 then a + c 

— X2 > b + c, identity of 

addition 

4 . (2/2 — X2) > next y 2 Definition of 

— next X2 next (from (S 6 )) 

5 - (2/2 — X2) > next Commutativity of next 

(«2 - x 2 ) 

Program Construction 

From the program format, the program is 

IDIV = (yi, 1/2) as soon as {y 2 < x 2 ); 

where 

first 1/1 = 0; 

first 2/2 = xi; 

next yi = 2/1 + F 

next V 2 - V 2 ~ x 2 \ 

end; 

The program is guaranteed correct because it was 
constructed through use of only mathematical ax- 
ioms and axioms about Lucid statements, so a formal 
proof is unnecessary. For comparison purposes, the 
program generated automatically is exactly the same 
as the one generated by hand and proven correct in 
the previous section Proof of Correctness of a Lucid 
Loop. The relationship between the automatic gen- 
eration and the formal proof becomes obvious upon 
comparison of the two. The axioms used in the proof 
are the same axioms used to generate the program, 
and the loop invariant and the termination condition 
are the key components driving both the code gener- 
ation and the poof of correctness. 

The Data Base 

The basic mathematical axioms and Lucid rules 
used to generate this simple example program are 
presented below. The basic axioms of mathemat- 
ical operations used in the example proof are the 
following: 
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a + 0 = a 
a * 1 = a 

a — a = 0 
a * 0 = 0 

a + (6 + c) = (a + b) 
+ c 

a * (b + c) = (a * b) 
+ (a * c) 


Identity of addition 
Identity of 
multiplication 

Identity of subtraction 
Substitution property 
of 0 

Associativity of 
addition 

Distributivity of 
multiplication over 
addition 


If a > b then a — c > b — c 
If a > b then c — b > c — a 
If a < b then a + c < b + c 
Substitution of equal variables 


The following axioms, described in the section Pro- 
gram Proving in Lucid for dealing with Lucid state- 
ments, are used in the example proof: 

Commutativity Axioms: 


For free variables x\, X2, x,- : 


first P = F’(xi/first xi, X2/first X2, •••) 
next P = P(x i/nextxi, X2/next X2, ■••) 
Lucid Termination Rule: 


integer P, P > next P \= eventually 


P < 0 

as soon as Induction Rule : 

first P, P A -i Q —> next P, eventually Q |= 
P A Q as soon as Q 


Constructing a Program From Other 
Specification Forms 

A loop is often specified in a form other than the 
invariant and the termination condition needed for 
the loop strategy. In this section some of the other 
forms of specifications and the construction of pro- 
grams from these forms are described. Some involve 
determination of a loop invariant and a termination 
condition from another form. Other forms lead to 
other program construction methods. 


Forall Clauses 

Routines specified by “forall” clauses ( “not exist” 
clauses) are routines for searching over a range. The 
forall clause is usually of the form 

Mu [range — > test_condition] 

This defines a search to ensure that all members 
within the range meet the test condition. The in- 
duction direction can often be determined from the 
termination condition. An example routine speci- 
fied with a forall clause is the following program to 
determine if two integers are relatively prime: 

pre: xi, X2 > 1 A (xi < X2) 

post: RPRIME (xi,X2) 

where 

RPRIME (ui , U2) = Mz (2 < z < u\ — * 

((tij DIV 2 / tti/z) V (U2 DIV z yf U2/z))) 

The range specified in this forall specification is 
integers between 2 and Uj, and the test condition is 
((ui DIV z ^ u\/z) V (u2 DIV z ^ U2/z)). The 
generated program according to this specification is 

RPRIME = (not(xi div y — x.\/y) or not 

(X2 div y — X2 /y)) as soon as (y = xi) or 

not (not(xj div y = x\/y) or 

not(x2 div y = X2 /y)) 

where 

first y = 2 ; 

next y — y + 1 ; 

end; 

The not exist clause is usually of the form 

-i 3 u [range A test_condition] 

This defines a search to ensure that no members 
within the range meet the test condition. An ex- 
ample routine specified by a not exist clause is the 
following specification for a routine to determine if 
an integer is prime: 

pre: x\ integer 

post: PRIME (xi) where 

PRIME ( u ) = -1 3 z [(2 < z < u) 

A ( u DIV z = u/z)\ 


11 



The not exist clause consists of the range 
(2 < z < u) and a test condition (uDIVz = u/z). 
The program that would be generated is 

PRIME = not (j/ = x ) as soon as ( x div 

V = x/y) 

where 

first y = 2; 

next y = y + 1; 

end; 

Exists Clauses 

“Exists” clauses contain an invariant upon which 
induction is performed. An example specification is 
the following one to determine a power of two larger 
than a given integer x: 

pre: x > 0 

post: (y 2 > x) A -1 3 2/1 ( 2 \ = y 2 ) 

This postcondition consists of an invariant 
( 2 1 = 2/2) and a termination condition (y 2 > x), 
which together define a loop. The program is 

POW 2 = 2/2 as soon as 2/2 > x 

where 

first 2/1 = 0; 

first 2/2 = 1; 

next 2/1 = 2/1 + 1; 

next y 2 = y 2 * 2; 

end; 

Other Constructs 

Many other constructs may also be found in 
program specifications, some of which specify loops 
and some of which specify other program structures. 
These have not yet been examined, but they would 
also be helpful in automatically generating a pro- 
gram. For example a conditional clause as described 
below calls for an if then else construct in the pro- 
gram instead of a loop. 

A clause containing subclauses separated by log- 
ical or’s (V) is a conditional clause. A conditional 
clause means an if then else structure will be needed 
in the program. An example is the following speci- 
fication of a program to find the maximum of two 
given integers: 


pre: xi, x 2 integers 

post: (( y = 11 A 11 > x 2 ) V (y = x 2 A x\ < x 2 )) 
The program to implement this conditional clause is 

COND = if xi > x 2 then x\ 

else x 2 ; 

Program generation using conditionals seems to be 
more straightforward when the specification is in 
subjunctive normal form (i.e., when the conditions 
are manipulated to contain subexpressions separated 
by logical or’s and there are no logical or’s within 
each subexpression). 

Another common specification form is to specify 
a routine as an inductively defined or a recursively 
defined function. The generation of such routines 
often clearly follows from the specifications. One 
example is the following recursive specification for 
a program to calculate factorials: 

post: y = FACTORIAL(x) 

where FACTORIAL(u) = if u — 0 then 1 

else u * FACTORIAL^ — 1 ) 

The program to implement this function is so simple 
it is one statement, and it is almost identical to the 
specification: 

FACT(x) = if x = 0 then 1 
else x *FACT(x-l); 

More Complicated Specifications 

In more complicated programs, the specifications 
are often combinations of several of the above con- 
structs, as in the following specifications for a routine 
for determining the greatest common divisor of two 
given integers: 

pre: x\ > 0 , X2 > 0 

post: {xi/y = x\DIVy ) A ( x 2 /y = x 2 DIVy ) A 
Vu [(u < y) — »• ((xi / u ^ x 1 DIV u ) 

V (x 2 / u ^ x 2 DIV u))} 

This postcondition consists of two termination con- 
ditions, {x\ / y = xi DIV y) and (x 2 / y — x 2 
DIV y), and the forall clause Vu [( u < y) — 1 ► ((xi / 
u ^ x 1 DIV u) V (x 2 / u ^ x 2 DIV u))]. The forall 
clause consists of the search range ( u < y) and the 
test condition ((xi / u ^ x\ DIV u) V (x 2 / u x 2 
DIV «)). 
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Limitations 

The strategy discussed in this paper, like all cur- 
rent strategies for automatic program generation, is 
extremely limited. Currently, only very simple and 
well-defined problems may be solved by automatic 
1 program generation. For life-critical applications, the 
expense of dividing a problem into simple pieces and 
developing the complete specifications needed for this 
type of strategy to work may be justified by the 
importance of reliability. Although there are few 
applications that meet this criterion, the ability to 
produce highly reliable software has many military 
and civilian benefits, including space exploration, 
autonomous processing, and highly efficient aircraft. 

The automatic program generation strategy re- 
quires all the axioms necessary for the proofs to be 
already in the data base or to be supplied by the user 
as needed. Similarly, the program generator can only 
handle program specifications in forms it knows how 
to analyze, because it depends on recognizing the 
form of the program. The strategy involves a one-by- 
one search over a range, so the program must search 
over a range of something that is countable, such as 
over a range of integers or a set. Obviously a one-by- 
one search over a range of real numbers is not pos- 
sible because they are uncountable, so the program 
generator strategy cannot presently solve a problem 
such as y — yjx. This is a serious limitation of the 
strategy. However, there are numerous applications 
with high reliability requirements, such as computer 


operating systems and flight-control-system mode 
logic, for which the strategy would work well. 

Concluding Remarks 

A strategy was described for automatically gener- 
ating programs from a precondition and a postcondi- 
tion. The strategy assumes that the algorithm to be 
used in the program is usually explicit in the program 
specification or can be easily deduced. The strat- 
egy proposes a one-step approach to the traditional 
two-step process of generating a program first and 
then attempting to perform a proof of correctness. 
Since there are numerous programs possible to solve 
any problem and some programs are easier to prove 
correct than others, this strategy eliminates the ini- 
tial educated guess at a provable program. Also, the 
strategy shows some promise for allowing the genera- 
tion of correct programs by less-skilled programmers. 
The strategy works well for the simple examples at- 
tempted in this paper with a variety of program spec- 
ification forms. Much more work should be done to 
apply the strategy to other types of programs and to 
more complex programs. Also, the problem of cor- 
rectly developing the low-level specifications needed 
for the strategy should be addressed. 

NASA Langley Research Center 
Hampton, VA 23665-5225 
March 17, 1987 
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